For decades, users have collaborated in substantially real time via multi-user, multi-device application sessions. Multi-player game sessions between two (or more) users on two (or more) devices, communicating via a network, are one common example.
Various facilities are known for connecting two users on distant devices to a common multi-device application session. However, many known facilities were developed for personal computer (“PC”) or game console gaming ecosystems and may not be suitable for newer computing platforms, such as mobile phones, computing devices embedded in televisions or set top boxes, and the like.
For example, Multiplayer Matchmaking facilities may allow a PC or game console user to connect to other PC or game console users playing the same game. Typically, the game will connect to a “matchmaking” service that stores a list of currently available game sessions. The user can view the game information such as map type, number of players in the session, and other game-specific parameters in this session list and select a session to join. The game would then connect to the server hosting the game session and the user can play with others in that session.
However, standard Multiplayer Matchmaking facilities may be unsuitable in “long tail” environments having a very great number of potential multi-device applications, many of which may have relatively few concurrent users at a given time.
For example, compared to PCs and game consoles, a mobile device such as an iPhone (or iPod Touch, iPad, or the like, all provided by Apple Inc. of Cupertino Calif.), tends to have simpler games and a lot more of them. The iPhone ecosystem includes many tens of thousands of game applications, leading to a very long tail of few users per game for almost all games (save a few very popular ones). Consequently, a list of all “sessions” currently available for any particular game would usually be empty, leading to a poor matchmaking experience. Furthermore, unlike many PCs that can act as their own game servers, many mobile devices such as the iPhone do not remain on and persistently connected to a network when the user is not using it. As a result, a mobile device such as an iPhone cannot typically host its own game server to supply a meeting ground for other players to join.
Moreover, because of the large number of applications and small number of users using each application, it may be economically unviable for many iPhone developers to maintain their own dedicated game servers to host multiplayer game sessions to join.
In addition, game console services such as Xbox Live, provided by Microsoft Corporation of Redmond Wash., host a notification system enabling one game console user to invite another game console user to play a game together. If the invitee game console user is signed-in to Xbox Live, his or her game console will periodically poll the Xbox Live service to determine whether he or she has any pending invitations.
Polling for invitations when a console user is signed-in may provide an acceptable user experience in a special-purpose gaming device (such as a gaming console) having a centralized, platform-provided, single-sign-on invitation system. However, non-gaming-specific computing platforms, such as mobile phones, computing devices embedded in televisions or set top boxes, and the like, may not offer a centralized single sign-on that authenticates the current user across multiple applications. Consequently, a remote invitation service may be unable to determine the identity of the user currently operating a given device at a given point in time. Moreover, repeatedly polling a remote service to check for pending invitations may adversely affect a mobile device's battery life.
Some device platform providers may provide a centralized, general purpose “Push” notification system. For example, various versions of the iOS mobile operating system, provided by Apple Inc. of Cupertino Calif., enable “Push Notifications” in which an application on the sender's device (e.g., an iPhone, iPod Touch, iPad, and the like) can send a notification to the receiver's device through the Apple Push Notification Service (“APNS”). The notification may (or may not) subsequently appear on the receiver's device. The receiver can typically dismiss the notification or accept the notification, which will launch the application with data stored in the message.
The APNS works only if both sender and receiver have installed the application in question, and if both users have run the application, and if the receiver's application has uploaded a “Push Token” to the server of the Push Notification Provider. Once the Push Token is uploaded to the APNS server. Once all of these conditions have been met, an application on another device can send an invite to the device that generated that Push Token.
However, standard Push Notifications provided by APNS may not be suitable for invitations to multi-device applications sessions because, inter alfa, APNS is a “best effort” system, meaning that a Push Notification is not guaranteed to be delivered. Therefore, if the sender wanted to send state in an invitation (for example, an opening chess move or poker bet), some additional persistence must be provided, otherwise the initial game state may be invalid if the logic of the application demands reliable delivery of messages. In addition, a Push Notification can convey only a limited amount of data, which may be insufficient to adequately convey state to the receiver.